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(54) Computer system with multiple operating system operation 

(57) A computer system is provided with a scheme 
to making the input and output device provided in a 
computer in common for a plurality of operating system, 
in a nujltiple operating system control unit operating a 
plurality of mutually distinct operating systems on one 
computer system. The computer system includes a plu- 
rality of operating systems, and OS switching unit tor 
switching a plurality of operating systems. The OS 
switching means makes reference to a preferential Inter- 
njpt table on the basis of an interrupt factor for switching 
to corresponding operating system and calls intenupt 
processing means incorporated in the operating sys- 
tem. 
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Description 

[0001} The present invention is directed to a data 
Inputting and outputting method to a peripheral devices 
In a computer system operating with a plurality of oper- 
ating systems on a single processor, and Is related to a 
control method for using the same peripherai device in 
common for a plurality of operating systems in common. 
Description of the Related Art 
[0002] In normal computer, one operating system Is 
operated. The operating system manages resources of 
the computer, such as a processor, a memory and a 
secondary storage device and performs resource 
scheduling so as to operate the computer efficiently. 
Here, there are various Itinds of operating systems. One 
is superior in batch process, another is superior in GUI 
such as an office work, the other is superior in a real 
time process. In order to bring out feature of a plurality 
of operating systems, there is a needs to execute a plu- 
rality of operating systems simultaneously on the single 
computer. For example, In case of a large size compu- 
ter, rt has been demanded to operate an operating sys- 
tem executing an on-line process associated with an 
actual business or an operating system for develop- 
ment. Also, it Is demanded to operate an operating sys- 
tem provided with GUI and an operating system 
superior In real time characteristics. 
[0003] As a mechanism for operating a plurality of 
operating systems on one computer, there is a virtual 
computer system {OS Series Vol. 11 , VM, Tomoo OKA- 
ZAKI, Kyoritsu Shuppan K.K.) which has been realized 
In a large size computer, In the virtual computer system. 
A virtual computer control program occupies and man- 
ages all hardware and make it virtual to form the virtual 
computer. A control portion forming the virtual computer 
makes e physical memory, an input and output device, 
an external interrupt and so forth virtual. For example, 
divided physical memory behave as If a physical mem- 
ory starting from zero address for the virtual computer. 
Unit numbers identifying the input and output device are 
also made virtual. Furthermore, by dividing a storage 
region of a magnetic disk to realize even making a mag- 
netic disk drive virtual. 

[0004] On the other hand, as a technotogy for pro- 
viding Interface for a plurality of operating system in one 
computer, there is a micro kernel. In the micro kernel, 
an operating system server for providing operating sys- 
tem function to be shown to the user on micro kernel, is 
established. The user utilizes a resource of the compu- 
ter via the server. By providing servers for each operat- 
ing system, it becomes possible to provide various 
operating system environments for the user 
[0005] For example, in case of a vehicle mounting 
navigation system, Importance is given for a real time 
characteristics for instantly responding to variation of 
external environment and a reliability as to not to stop 
the system. Therefore, a real time operating system 
(real time OS) having a compact module construction 



with high interruption response is frequently used. How- 
ever, the real time OS cannot be said to have superior 
intertace with a person, while it gives Importance for real 
time characteristics and reliability. On the other hand. 

5 an office woric operating system (general purpose OS) 
to be typically used In typical pefsonal computer (PC) is 
provided an environment for directly operating a display, 
such as GUI to provide superior human interface. 
Therefore, a demand to use a user interface of the gen- 

w eral purpose OS even in the field where the real time 
OS has been used conventionally. Is growing, i-lowever, 
since the general purpose OS takes interactive process 
with the person, it gives greater importance for a 
throughput of the process rather than response charac- 

15 teristics to interrupt process and thus is possible to exe- 
cute a process with maintaining inten'upt inhibiting 
condition for a relatively long period. On the other hand, 
in comparison with the real time OS having compact 
construction, It cannot be said comparable In reliability. 

20 [0006] However, simllarty to a system for operating 
a plurality of virtual computers (operating systems) In 
parallel on the large size computer, if the general pur- 
pose OS and the real time OS can be operated in the 
same computer system in a build-in system to switch 

25 the operating system as required, it may be possible to 
achieve both of superior used Interface and real time 
characteristics and reliability. Considering improvement 
of perfomiance of the microprocessor, operating a plu- 
rality of operating systems in one computer systerii has 

30 not been a technology permitted only the large size 
computer. 

[0007] While It is required to be adapted for multiple 
users in the large computer, whereas a built-in equip- 
ments may be required to be at least adapted to a single 

35 user in the build-in equipments. Therefore, when the 
real time OS and the general purpose OS are operated 
in the single system, a simplest operating system 
switching method In consideration of importance of 
respective operating systems, if a process to be exe- 

40 cuted In the real time OS Is present, to operate the real 
time OS preferentially and to operate the general pur- 
pose OS when the task to be executed on the real time 
OS is not present, is applk;able. in such switching 
method the operating systems, a method of switching of 

45 the operating system by discriminating the interrupt 
number generated, by statically detemnining the operat- 
ing system receiving the interrupt demand per input and 
output devices in inputting and outputting with the 
peripheral device. For example, when the foregoing 

so method is applied to the vehicle mounted navigation 
system, the operating system Is switched so that an 
Interrupt handler of the real time OS is actuated for the 
interrupt from the sensor necessary for detemriining the 
position and an interrupt handler of the general purpose 

55 OS is actuated for interupt from a display controller. 
However, since the reliability of the general purpose OS 
is not necessarily high, In the shown application, proc- 
ess of the general purpose OS is stopped, the user 
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interface becomes impossible to use to lower renability 
of the overall vehicle mounted navigation system. In 
order to solve the foregoing problem, the process may 
be divided to assign the process v^^hich is desired to 
never be interrupted to the real time OS side and to 5 
assign the process permitting interruption to the general 
purpose OS side. However, if the input and output proc- 
ess for the user interface is process on the side of the 
real time OS, introduction of the general purpose OS 
superior in user Interface becomes meaningless. There- 10 
fore, it becomes essential to permit use of the input and 
output device from a plurality of operating systems, 
namely from both of the general purpose OS and the 
real time OS. Therefore, a problem is encountered in 
that it is insufficient to statically determine the operating 15 
system to execute the input and output process from the 
inten\jpt number as set forth above, and cannot be 
applicable for practical use. 

[OOOB] An object of the present invention to provide 
a scheme to making the input and output device pro- 20 
vided in a computer In common for a plurality of operat- 
ing system, in a multiple operating system control unit 
operating a plurality of mutually distinct operating sys- 
tems on one computer system. 

[0009] In order to accomplish the above-mentioned 25 
object, According to the first invention, a computer sys- 
tem including a plurality of operating systems, and an 
OS switching means for switching a plurality of operat- 
ing systems, characterized in that said OS switching 
means makes reference to a preferential interrupt table 30 
on the basis of an interrupt factor for switching to corre- 
sponding operating system and calls interrupt process- 
ing means incorporated in said operating system for 
making the input and output device provided in the com- 
puter system in common for a plurality of operating sys- 35 
lems.. 

[001 OJ According to the second invention, a compu- 
ter system having a plurality of operating systems and 
OS switching means for switching a plurality of operat- 
ing systenns, characterized by Including peripheral 40 
device to be common for a plurality of operating sys- 
tems, data inputting and outputting server for Inputting 
and outputting data with the peripheral device to be 
used in common, providing in one of the operating sys- 
tems, data inputting and outputting client for inputting 4$ 
and outputting data with the operating system other 
than said one operating system, requesting inputting 
and outputting data to said data inputting and outputting 
server and executing inputting and outputting of data by 
receiving a result of data inputting and outputting with so 
the periphenal server In the data Inputting and outputting 
server. 

BRIEF DESCRIPTION OF THE DRAWINGS 

55 

[0011] The present invention will be understood 
more fully from the detailed description given hereinaf- 
ter and from the aoconf^anying drawings of the pre- 
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ferred embodiment of the present Invention, which, 
however, should not be taken to be limitative to the 
invention, but are for explanation and understanding 
only 

[0012] In the drawings: 

FIG. 1 is an illustration showing a system construc- 
tion in the first embodiment of the present invention; 
FIG. 2 is an illustration showing a hardware con- 
struction of a computer system; 
FIG. 3 Is an illustration showing a status register in 
the case where an interrupt level mask function is 
provided; 

FIG. 4 is an illustration showing a status register in 
the case where an Individual interrupt mask func- 
tion is provided. 

FIG. 5 is a first illustration showing a detail of an 

interrupt processing program; 

FIG. 6 Is an illustration showing a construction of 

the Interrupt address table; 

FIG. 7 Is an illustration showing a construction of a 

preferential intemjpt table; 

FIG. 6 is an illustration showing a process flow of an 

OS context switch module; 

FIG. 9 is a first illustration showing a process flow of 

a common intenrupt handler; 

FIG. 1 0 is a first illustration showing a process flow 

of an intemipt handler; 

FIG. 1 1 is an Illustration showing a construction of 
an Input and output panel of a vehicle mounted nav- 
igation system; 

FIG. 12 is an illustration showing a construction of a 
switch table; 

FIG. 13 is a second Illustration showing the process 
flow of the common Interrupt handler; 
FIG. 14 is a second illustration showing the system 
construction In the second embodiment of the 
present invention; 

FIG. 15 is a third illustration showing the process 

flow of the common interrupt handler; 

FIG. 1 6 is a second illustration showing the pmcess 

flow of the inten-upt handler; 

FIG. 17 is a third iliustnation showing the process 

flow of the intenupt handler; 

FIG. 16 Is a first illustration showing a detail of an 

input and output processing program; 

FIG. 19 is a second illustration showing a detail of 

an input and output processing program; 

FIG. 20 is an illustration showing a flow of re-writing 

a preferential interrupt table; and 

FtG. 21 is an illustration showing a construction of a 

system in which the present Invention is applied to 

a graphic display device. 

[0013] The present Invention will be discussed 
hereinafter in detail in terms of the preferred embodi- 
ment of the present invention with reference to the 
accompanying drawings. In the following description, 
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numerous specific details are set forth in order to pro- 
vide a thorough understanding of the present invention. 
It will be obvious, however, to those skilled in the art that 
the present Invention may be practiced without these 
specific details. In other instance, well-known structure s 
are not shown in detail in order to avoid unnecessary 
obscurity of the present invention. 
[001 4] Enrtbodlnr^ents of a computer system accord- 
ing to the present invention will be discussed with refer- 
ence to the drawings. to 
(0015] An overall construction In the first embodi- 
ment of the computer system according to present 
Invention is illustrated in Rg. 1. Nonnally, a computer 
system is constructed with a processor 100, a memory 
101, an input and output control device 102, a display i5 
1 04, a switch 1 05, a sensor 1 06 and so forth. The proc- 
essor 100, the memory 101 and the input and output 
control device 102 are connected by a processor bus 
103. The processor 100 is a microprocessor for operat- 
ing a plurality of operating systems. The memory 101 20 
stores operating systems 116 and 117, task programs 
1 10 to 115 operated on respective operating systems, 
input and output driver programs 120 and 121 for 
respective operating systems, interupt handler pro- 
grams 122 and 123, and inter-OS control function pro- 2S 
gram 124. These programs are read from the memory 
101 and executed by the processor 100. 
[0016] The Input and output control device 102 is 
connected with a display 104 as an image display 
device, a switch 1 05 for receiving a command from a 30 
user, a sensor 106 for detecting variation of peripheral 
environment and so forth. On the other hand, upon real- 
izing a factory/plant controlling or built-in computer sys- 
tem, B network 109 may be connected to the input and 
output control device 1 02. To the network 1 09, an input 35 
and output equipment, such as a communrcation equip- 
ment and so forth, is connected. It should be noted that 
among input and output devices 104 to 106 connected 
to the input and output control device 1 02, any one or alt 
of the Input and output devices may be omitted in some 4a 
system configuration. Furthermore, wide variety of Input 
and output devices may be connected for notifying com- 
pletion of Input and output operation and so forth. In Fig. 
1, while the interrupt signal line 108 and the processor 
bus 103 are illustrated as separate devices for the pur- 45 
pose of illustration, the interrupt signal line is a part of 
the processor bus 103, in practce. Within the processor 
100, a timer device 107 is provided to cause an internal 
inten^ipt per a given period. An interrupt caused by the 
timer device 107 is used for time measurement of the so 
operating system or the like. 
[0017] The processor 100 is provided with a func- 
tion for masking an external inten'upt command input 
through the interupt signal line 108 and an Internal 
Inten'upt command from the timer device 107 and so 55 
forth. The masking of Interrupt is a function for delaying 
a particular interrupt until masking of intenupt is 
released by a program. Typically, as the intenupt mask- 



ing functions, the following three kinds are present. 

(1) All Interrupt Mask: All of interrupts are masked. 

(2) Individual Interrupt Mask: Each individual inter- 
rupt is masked. 

(3) Interrupt Level Mask: Level is set for each inter- 
rupt for masking interrupt lower than or equal to a 
designated level. 

[0018] Depending upon kind of the processor 100, 
inten^upt masking of a combination of the foregoing (1) 
and (2) or a combination of (1 ) and (3) may be provided, 
frequently When the processor having the latter combi- 
nation is employed, the inten-upt level is assigned 
depending upon importance and minimum response 
period of the corresponding input and output device. For 
example, an inten-upt from a network requiring a short 
response period is set at higher level than that of the 
interrupt from the switch 105, the storage device 106 
and 80 forth. 

[0019] In the shown embodiment, discussion will be 
given for the case where two operating systems 1 1 6 
and 1 17 are present in the computer system. The oper- 
ating systems 116 and 117 execute tasks 110 to 115 
using memory assigned for each operating system and 
a resource of the processor. While Fig. 1 shows an 
example where number of operating systems is two and 
total number of the tasks is six. it is possible to load the 
operating systems or tasks In greater or smaller number 
than that Illustrated. While the shown embodiment does 
not consider dynamic variation of number of the operat- 
ing systems, it is possible that each operating system 
dynamically generate and delete the takes. Further- 
mo rie, in the shown embodiment, it is assumed that the 
operating system 1 1 6 is the general purpose OS which 
is adapted for word processing, data processing and so 
on and the operating system 117 is the real time OS 
which requires real time response, such as computer 
games, navigation system and so forth. However, the 
technology descried in the present invention is applica- 
ble for any kind of the operating systems. The tasks 11 0 
to 1 12 are tasks to be executed by the general purpose 
OS, and the tasks 113 to 115 are real time tasks to be 
executed by the real time OS. Also, the following discus- 
sion will be given with an assumption that preferential 
order of interrupt of the real time OS is higher than that 
of the general purpose OS In order to guarantee a 
response period in the real time OS. In the assumption, 
when any one of the tasks of the real time OS is in exe- 
cution, the real time OS 116 uses the resource of the 
processor. When all of the tasks are in idling condition 
or watting condition, the context is switched to the gen- 
eral purpose OS so that the general purpose OS uses 
the resource of the processor. 
[0020] The inter-OS control function 1 24 is provided 
for operating the general purpose OS 1 16 and the real 
time OS 1 17 in cooperation with each other. The inter* 
OS control function 124 includes a common memory 
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125 accessible from both of the general purpose OS 
and the real time OS, an inter-OS communication func- 
tion 1 26 for performing transfer of message between the 
general purpose OS and the real time OS, an OS con- 
text switching function 1 27 for switching executing envi- 5 
ronment of the general purpose OS and the real time 
OS, a common Interrupt handler 12B for distributing the 
generated interrupt commands to respective operating 
systems, and a preference management table 1 29 stor- 
ing the operating systems corresponding to the interrupt 10 
demands or interrupt start addresses. 
[0021] The common memory 125 intends the real- 
ize high speed data exchange between the operating 
systenns and can read and write out and in by both of 
the general purpose OS and the real time OS. Here, in 75 
order to avoid conflict of data. It Is desirable to exciu* 
siveiy access the common memory using a semaphore 
function. The Inter-OS communication function 126 pre- 
pares a message queue corresponding to respective 
operating system for transferring the message between 20 
respective operating systems. The common interrupt 
handler128 initially call upon generation of the Intenupt 
demand to detennine the operating system per interrupt 
number stored in the preferential intenrupt table 129 to 
call the corresponding interrupt handler 122 and 123. 25 
The OS context switching function 127 switches context 
as judged that switching of the operating system is nec- 
essary in response to the interrupt demand or calling of 
Inter-OS control function. The interrupt management 
table 129 stores the operating system information, in 30 
which the intenrupt handler called per intenojpt number 
belongs, and start address information of the intemipt 
handler per operating system. In the conventional 
method, the interrupt management table 129 statically 
determines upon starting up of the system. Therefore, 35 
the content could not be re-written during system oper- 
ation. In the shown system, by providing re-writing 
means for re-writing the intenijpt management table 
129 even during system operation, common use of one 
input and output device with a plurality of operating sys- 40 
terns is enabled. 

[0022J The operating systems 1 1 6 and 1 1 7 has the 
input and output drivers 120 and 121 for processing 
data input and output with the input and output device 
and the intenrupt handlers 122 and 123 for receiving 45 
Intenrjpt demand from the Input and output devices. 
The intemjpt handlers 122 and 123 are called from the 
common interrupt handler 128. One of the interrupt han- 
dlers 122 and 123 called by the common intemjpt han- 
dler 1 28 executes interrupt processing program defined so 
by the user. The input and output drivers 120 and 121 
provide interfaces for controlling the input and output 
devices and provide functions for inputting and output- 
ting data by reading and writing data from and In the 
input and output device and controlling the Input and 55 
output device. Re-schedulers 1 18 and 1 1 9 initiate oper- 
ation In the case where taslc has to be switched associ- 
ating with generation, deletion, stopping, and restoring 



of tasic, external intemjpt or internal interrupt. The re- 
scheduler stores execution environment (program coun- 
ter, status register, general purpose register and so 
forth) of the task executed Immediatefy before In a tasl< 
management table, determines to be newly executed, 
takes out the execution environment from the tasl( man- 
agement table to set in respective registers to execute 
the selected taslc. 

[0023] Fig. 2 shows an example of internal con- 
struction of the processor premised in the present 
invention. A cache memory 130 is a buffer storage 
device for temporarily storing data or instruction on the 
memory 101, CPU 131 is an arithmetic circuit and 
sequentially executes Instructions present on the mem- 
ory 101 or the cache memory 130. Upon execution of 
the instruction, a general purpose register 132 tempo- 
rarily storing the result of arithmetic operation, a pro- 
gram counter 133 for storing an execution instruction 
address and a status register 134 for storing execution 
status. The cache memory 130. CPU 131, the general 
purpose register 132, the program counter 133, the sta- 
tus register 134 are connected with each other by a data 
bus 135 for transferring data and an address bus 136 
perfomning address designation. 
[0024] The interrupt signal line 106 and the timer 
device 107 are connected to an interrupt controller 137. 
The interrupt controller 137 has a function for generat- 
ing intenrupt state signal 138 with respect to CPU 130. 
The inten-upt state signal 138 is a signal line indicating 
what kind of interrupt is currently occunred on the proc- 
essor 100. Normally, the status register 134 has infor- 
mation relating to current interrupt mask to determine 
whether Inten-upt designated by the inten^upt status sig- 
nal 138 is accepted or not. Upon accepting interrupt, the 
interrupt controller 1 37 re-wrltes the program counter 
133, the status register 134 and so forth to execute cor- 
responding interrupt processing program. 
[0025] An example of structure of the status register 
134 is shown in Rg. 3. Here, an example of the case 
where all Interrupts masking function and inten-upt level 
masking function are provided in the processor 100. In 
the example of Rg. 3, the status register 134 has an 
interrupt block bit 140 and an interrupt mask level field 
141. When the interrupt block bit 140 ts ON, all Inter- 
rupts to the processor 100 is masked. The interrupt 
mask level field 141 shows the cunrent interrupt mask 
level value, and interrupt level lower than or equal to this 
level is not accepted. In case of the example shown in 
Rg. 3, the inten-upt mask level field 141 has a length of 
four bit length. Therefore, sbcteen kinds in total of the 
mask levels can be designated (normally, the interrupt 
level 0 represent "interrupt does not occur", and thus fif- 
teen kinds in practice). By varying the bit number of the 
Interrupt mask level field 141, kind of the intemjpt level 
to accept can be Increased and decreased. 
[0026] Rg. 4 shows the status register 134 for the 
case where the processor 100 is provided with all Inter- 
rupt masking function and individual interrupt masking 
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function. In this example, the status register 134 is con- 
structed with two registers (an execution status register 
142 and in interrupt masking register 143). Similarly to 
Rg. 3, the interrupt block bit 140 In the execution status 
register 142 is provided. Intenrupt masic bits 144 to 147 5 
in the Interrupt masking register 143 correspond to 
Intemjpt separately. When any one of the intenrupt 
mask bits Is turned ON, reception of the corresponding 
intemipt is prohibited. The example of status register 
shown In Fig. 3 Is special example of the status register fo 
134 of Fig, 4. For example, a state where only intemjpt 
mask bit 144 is ON, is referred to as level 1. When two 
of the interrupt mask bits 144 and 145 are ON, the state 
is refenred to as level 2. When three of the interrupt 
mask bits 140 to 146 are ON, the state is referred to as 75 
level 3, ... for establishing correspondence. Therefore. In 
the following disclosure, the status register 134 will be 
discussed to have the construction shown In Fig. 4. 
[0027] In genensil processor, upon reception of 
intemjpt, the intenrupt block bit 140 Is automatically re- 20 
written to ON by hardware. As required, the intenxipt 
processing program re-writes the intenupt block bit 140 
to OFF to enable accepting interrupt. On the other hand, 
it is also possible to temporarily re-write the contents of 
the Interrupt block bit 140 and the interrupt mask regis- 25 
ter 143 by the operating system and the task to place 
the system to wait for reception of a particular interrupt. 
The interrupt masking function Is used for realizing 
exclusive control and avoiding occun-ence of the same 
interrupt during execution of interrupt process. 30 
[0028] Rg. 5 shows detail of the interrupt handlers 
122 and 123, the common interrupt handler 128, the OS 
context switching function 127 and the tnten-upt man- 
agement table 129. 

[0029] The intemjpt handler 122 and 123 have 35 
interrupt stacks 151 and 153 respectively as regions for 
storing register and so forth upon occurrence of inter- 
rupt and storing a temporary parameter. The interrupt 
stacks 151 and 153 are provided for storing register 
value immediately before occurrence of Interrupt and 40 
returning the register value to the original value after 
completion of the inten^pt process, upon occun-ence of 
intenrupt Some kind of processor 100 to be used, a 
function to automatically switch the register upon occur- 
rence of interrupt and to return to the register before 45 
switching after the interrupt process. However, in con- 
sideration of the system permitting multiple Intemjpts, 
stack becomes necessary even in using such hardware 
(when interrupt having higher preference occurs during 
process of interrupt, the newly occurred intenrupt proc- so 
ess is executed preferentially, and then has to return to 
the original intemjpt process). The interrupt handlers 
122 and 123 has intenvpt stack pointers 150 and 152 
as pointers showing what region is used in the tnten-upt 
stacks 1 51 and 1 53. The intenupt handlers 1 22 and 1 23 55 
store execution environment (register and so forth) 
using the intenupt stack pointer to execute necessary 
interrupt process. After completion of the intenrupt proc* 



ess, the execution environment before occurrence of 
interrupt Is resumed to continue originally executed pro- 
gram, 

[0030] The common intenrupt handler 128 has a 
function for distributing occurred interrupt to the inter- 
rupt handlers 122 and 123. Therefore, the conrvnon 
interrupt handler 128 has an executing OS storage 
parameter 1 54 as a region for storing which of the gen- 
eral purpose OS 116 and the real time OS 117 is the 
operating system currently executed. For example, 
assuming that the general purpose OS is In execution at 
the time of Fig. 5. 'general purpose 05" is stored in the 
executing OS storage parameter 154, In this case. Of 
course, since it is quite inefficient to store the character 
string 'general purpose OS" In the executing OS stor- 
age parameter 1 54, it may be stored in a form of integer, 
such that 0 is stored if the general purpose OS is in exe- 
cution and 1 1s stored if the real time OS Is in execution. 
[0031] The intenrupt management table 129 has a 
preferential intenojpt table 1 56 indicating whtoh interrupt 
handler of one of the operating system is to be actuated 
and an inten'upt address table 155 indicating a start 
address of the interrupt handlers included In respective 
operating systems. The preferential intenrupt table 156 
is constnjcted with a correspondence table Indicating 
which of the operating systems processes the individual 
interrupt as shown in Rg. 7, for example to request 
process to the interrupt handler of the operating system, 
for which the flag 1 is stored. Furthermore, for interrupt 
from the input and output device common for a plurality 
of operating systems, flag is set to 1. and not common 
intemjpt, flag 0 is stored. In the shown embodiment, 
assuming that sixteen kinds of intemjpt factors are 
present, the interrupt correspondence table 156 Is 
formed with sixteen entries (IRQ#0 to IRQ#15), In this 
disclosure, it is premised a method for storing a flag in a 
preferential driver table 160, it may be realized by any 
method by storing some Identifiable Information. The 
interrupt address table 155 is a table holding start 
address of the intemjpt handler Included In each oper- 
ating system as shown in Rg. 6, for example. 
[0032] In the present Invention, In order to achieve 
the object to use one input and output equipment for a 
plurality of operating systems in common, a mechanism 
for dynamteally varying the operating system to be actu- 
ated from the interrupt demand received by the com- 
mon Inten'upt handler 128. The content of the 
preferential inten'upt table 156 is updated depending 
upon the user operation and use condition of the input 
and output equipment. The common interrupt handler 
128 operates to call interrupt handler according to the 
content of the preferential interrupt table 156. In further 
detailed discussion, the common interrupt handler 126 
make reference to the executing OS storage parameter 
154 to make judgment of the kind of the currently exe- 
cuted operating system. If the kind of the operating sys- 
tem does not match with the operating system to be 
assigned obtained from the preferential interrupt table 
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154, switching of the operating system is requested to 
the OS context switch module 127. Upon completion of 
switching of the operating system or If the operating sys- 
tem matches and thus switching is unnecessary, proc- 
ess is requested to the inten'upt handler of the 5 
corresponding operating system. It should be noted that 
the executing OS storage parameter 154 is made refer- 
ence to even from the OS context switch module 127. 
The Internal structure having respective modules in the 
inter-OS control function program, is not limited to that to 
occupied by individual modules but can be common In 
respective modules as required. 
[0033] The OS context switch module 127 Is actu- 
ated when the operating systems are to be switched as 
a result of calling of the inter-OS control function or 15 
occurrence of Interrupt. In order to switch between the 
operating systems, the region for storing the execution 
environment (namely, register value) is provided. In the 
drawing, as the region for storing the execution environ- 
ment of the general purpose OS In the drawing, a stor- so 
age context for general purpose OS 1 57 is prepared, 
and as a region for storing execution environment of the 
real time OS. a storage context 1 58 for real time OS is 
prepared. The OS context switch module 1 27 stores the 
execution environment in the storage context conre^ 25 
spending to the currently executed operating system 
upon switching of the context. Next, the execution envi- 
ronment is read out from another storage context to set 
in the register of the processor 1 00. By this, switching of 
the operating system can be perfomied. Subsequently, 30 
discussion will be given for process flow of the OS con- 
text switch module 127, the common inten'upt handlers 
128 and the interrupt handler 122 among the modules 
shown in Rg. 5. Concerning the interrupt handler 123, 
since it has the same flow as the intenupt handler 122, 35 
discussion will be omitted. 

[0034] Fig. 8 is a process flow of the OS context 
switch module 127. The OS context switch module 127 
Is called only when the operating systems to be exe- 
cuted are to be switched. Checking whether switching is 40 
necessary or not. is performed before calling. Accord- 
ingly, with reference to the executing OS storage param- 
eter 154, check is perfomied as to which operating 
systems switching is to be made (process 160). Here, 
upon switching from the general purpose OS 1 1 6 to the 4S 
real time OS 1 1 7. the value of the register being used is 
temporarily stored in the storage context 1 57 for the 
general purpose OS (process 161). Then, by resuming 
the execution environment from the storage context 1 58 
for the real time OS to set In the register (process 1 62), so 
the real time OS can be re-executed from the temporar- 
ily stored condition. Upon switching from the real time 
OS to the general purpose OS, conversely, the value of • 
the register being used is temporarily stored in the stor- 
age context for the real time OS (process 163). Next, ss 
the register 157 is resumed from the storage context 
157 for general purpose OS (process 164). In either 
case, finally, the kind of the operating system after 



switching is written in ttie executing OS storage param- 
eter 154 (process 165). 

[0035J Rg. 9 shows the process flow of the com- 
mon interrupt handler 128. In general, in the computer 
system controlled by a single operating system, all of 
interrupts are once processed by a module called as 
interrupt handier, then is distributed to respective pro- 
grams. However, in case of the computer system oper- 
ating a plurality of operating system as discussed in the 
shown embodiment, all interrupts are received by the 
common interrupt handler furtiier before to distribute 
the interrupts to the interrupt handlers of tiie conre- 
spending operating systems. Upon distribution of Inter- 
rupts to respective operating systems, upon occurence 
of Interrupt, it Is possible that the operating system other 
than objective for interrupt is in execution. In this case, It 
becomes necessary to switch to the operating system 
corresponding to interrupt The common Inten'upt han- 
dler also has such function. 

[0036] The common handler 128, at first, takes out 
the content of the executing OS storage parameter 154 
to check whether the operating system currently exe- 
cuted is the general purpose OS 1 1 6 or the real time OS 
117 (process 170), upon occurrence of interrupt. Next, 
reference Is made to the preferential intenupt table 156 
to attain which of the Intenupt handier of the operating 
systems is to be actuated by the generated interrupt 
demand (process 171). Considering the case where the 
value in the preferential interrupt table 156 shown in Rg. 
6 Is used, the operating system con'esponding to the 
value can be attained in such a manner that when the 
interrupt IRQ#0 occurs, the real time OS. when the 
interrupt IRQ#1 occurs, the general purpose OS 1 17, ... 
when the intemjpt IRQ#15 occurs, the real time OS 
117. Next, check is performed whether the obtained 
Interrupt objective operating system matches with the 
operating system in execution or not (process 172). If 
the interrupt demand is not for the cunrentiy executed 
operating system, the operating system has to be 
switched once. This switching process is performed by 
requesting switching to the OS context switch module 
127 (process 173). Next, check is perfomried whether 
tiie Inteoupt objective operating system is the general 
purpose OS 1 16 or the real time OS 1 17 (process 174). 
If the object Is the general purpose OS 1 1 6, the interrupt 
handler 122 of the general purpose OS is actuated with 
reference to the Intemjpt address table 155 (process 
175). If interrupt is caused In the real time OS 1 17, ref- 
erence is made to the interrupt address 155, similarly, , 
tiie interrupt handier 123 of the real time as is actuated 
(process 176). in general, when switching of task has to 
be performed In the interrupt process, the inten'upt han- 
dler 1 22 and 1 23 calls the re-schedulers 1 1 8 and 1 1 9 so 
as not to return the control to the common intenoipt han- 
dler 128. However, when task switching does not occur, 
the process of the intenupt handler is terminated. At this 
time, the interrupt handlers 122 and 123 returns control 
to the common interrupt handler (discussed later in con- 
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nection with Rg. 10), and the common intemjpt handler 
resumes operation from process 177. Process 177 is a 
process for checking whether the operating systems are 
switched upon occun^ence of intemjpt When the oper- 
ating system is switched at process 1 73, the operating 5 
system has to be switched again to return to the original 
execution environment. Therefore, request is made to 
the OS context switch module 127 for execution of the 
switching process (process 176). 

[0037] Rg. 1 0 shows a process flow of the inten-upt w 
handler of the general purpose OS called from the com- 
mon interrupt handler 128. At first, the register in use is 
temporarily stored In the interrupt stacic 151 (process 
180) to execute the interrupt process (process 181). 
Here, check is made whether the operating system is in is 
re-scheduiing or not (namely, whether the re-scheduler 
is in execution of the process or not) (process 182). In 
re-scheduling means that the take to be executed next 
is now in selection, and the task is not actually in execu- 
tion/ Accordingly, when the process of the operating 20 
system can be simplified, the re-scheduling in this case 
can be done again from the beginning. Namely, when 
judgment is made that the re-scheduling is current in 
execution, the temporarily stored register of the inter* 
nipt stack is abandoned (process 1 87) to actuate the re- 25 
scheduler 118 from the beginning (process 188). It 
should be noted that there is some cases, In which the 
task In execution Is not necessary to be newly selected 
even when intemjpt occurs during re-scheduling. In the 
shown system, even in this condition, rescheduling has 30 
to be performed from the beginning and thus is not effi- 
cient Therefore, it is possible to employ a method to 
register the process (e.g. task Initiation, termination and 
so forth) possibly influence for execution of the re- 
scheduler 118, occurring during re-scheduling in a 35 
queue. In this case, the process registered in queue 
before completion of re-scheduling, is executed aggre- 
gatlngly When this system is employed, it becomes 
unnecessary to re-do re-scheduling executed to the 
mid-way at every occurrence of Interrupt However, after 40 
aggregatingly executing the process stored in the 
queue, check has to be done again whether re-schedul- 
ing is to be performed or not It should be noted that, in 
the shown embodiment, discussion wilt be given with 
the fomier system for simplification. However, when the 45 
latter system is employed, a flag indicative of re-sched- 
uling being in process or not or a process queue may be 
prepared. In system call or so forth provided by the 
operating system, the process influencing for execution 
of the re-scheduler 118 Is registered ion queue if re- so 
scheduling is In execution. Furthermore, during process 
flow of re-scheduler 118, a module to aggregatingly 
executing the processes registered in queue is inserted. 
[0038] When the interrupt handler 1 22 makes judg- 
ment that the re-scheduling is not in execution, the oper- 55 
ating system should be in execution of certain task at 
that timing. Therefore, at first, check is made whether 
task switching is necessary or not (process 183). If 
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switching of the task is unnecessary (curently executed 
task Is the highest preferential order and is executable), 
the process of the Intemjpt handler 122 is terminated 
with no change. Therefore, the register value temporar- 
ily stored in the Intemjpt stack 151 is recovered (proc- 
ess 184) and control is returned to the common 
inten-upt handler (process 185). If Judgment is made 
that switching of the task is necessary, the value of the 
register temporarily stored in the inten-upt stack 161 is 
copied to the task management table (process 1 86), the 
temporarily stored register of the inten-upt stack is aban- 
doned (process 187) and then the re-scheduler 1 18 is 
actuated (process 188). It should be noted that if the 
process 1 00 is provided with a function to increase and 
decrease the value of the intenupt stack pointer 150 
together with making reference to data on the memory 
101. the processes 186 and 187 can be executed in a 
lump. 

[0039] As set forth above, the method for using the 
Input and output device In common for a plurality of 
operating systems by making reference to the preferen- 
tial interrupt table 156 provided in the inter-OS control 
function 124, and actuating the inten-upt handler after 
detemninatlon of the operating system to be operated. 
However, It is possible to occur the case where the 
operating systems cannot be uniformly determined from 
the inten-upt number for some input and output device. 
For example, in an input and output panel of a vehicle 
mounted navigation system shown in Fig, 1 1, for exam- 
ple, a switch 105 for Inputting a command by the user 
and a display 104 for displaying a result are provided. 
The switch 105 preferably Includes a dedicated switch 
190 for real time OS, which is used by only tasks pro- 
vided In the real time OS 1 1 7, a dedrcated switch 1 91 for 
office work and a common switch 192 which can be 
used in common from the tasks provided in both of the 
operating systems. By providing the dedicated switches 
per operating system, frequently used function can be 
fixedly assigned to the switches to attain a feature to 
improve operability. Furthemiore, by assigning the func- 
tion to the fixed switch, function name can be displayed 
on the button to improve identlfiablllty. However, provid- 
ing distinct interrupt number per switch is disadvanta- 
geous In viewpoint of constraint of number of interrupt 
signal lines and simplification of the hardware. On the 
other hand, by assigning the same Intenrupt number to 
the switches, It becomes Impossible to determine which 
interrupt handlers of the operating systems is to be 
actuated upon depression of the switch. In order to 
solve this problem, a switch table 200 is provided In the 
common memory 125 provided in the inter-OS control 
function 124. In the switch table, information of the 
switch to be used by which operating system is stored 
per switch, in Fig. 12, in the switch table, "real time OS", 
•general purpose OS' and "common" are stored. Of 
course, storing the character string in the table is quite 
inefficient, the Information may be stored In a form of 
Integer, such as if the operating system is real time OS, 
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0 is stored, if the general purpose OS. 1 is stored, and if 
common, 2 Is stored. 

[0040] Next, a process flow of the common interrupt 
handler 128 using the input and output device in com- 
mon for a plurafity of operating systems using the fore- 
going switch table 200, will be discussed with reference 
to Rg. 13. The process discussed herein is applicable 
not only for the switch but also for other input and output 
device which require determination which operating 
systems is to be actuated by malcing judgment of the 
content of Intenupt 

[0041] The common interrupt handler 128 malces 
reference to the content of the executing OS storage 
parameter 154 after occurence of interrupt to check 
whether the cun-ent executed operating system is the 
general purpose OS 1 1 6 or the real time OS 1 1 7 (proc- 
ess 210). Next, reference Is made to the preferential 
intenupt table 156. If the common flag Is not set. the 
operating system, to which the occurred interrupt corre- 
sponds, is attained with reference to the preferential 
Inten-upt table 156 (process 212). If the common flag is 
set, the intemjpt objective operating system is deter- 
mined by malcing judgment of the content of interrupt by 
accessing the input and output device (process 21 3). 
IHere, comparing the content of intenupt and the switch 
table 200, when Judgment is made that the dedicated 
switch for the real time OS is depressed, the real time 
OS 117 is stored as the Inten-upt objective OS, and 
when judgment is made that the dedicated switch for the 
general purpose OS is depressed, the general purpose 
OS 116 is stored as the interrupt objective OS. When 
Judgment is made that the common switch is 
depressed, reference Is made to the preferential Inter- 
rupt table 156, the operating system, to which the 
occurred intenupt corresponds, is attained. Here, con- 
sidering the case where the stored values in the prefer- 
ential Inten-upt table 156 of Fig. 7 and the switch table 
200 of Rg. 12 are used, if IRQ#2 is assigned to switch 
intenupt, when the switch #0 is input, reference is made 
to the real time OS, when the switch #2 is input, refer- 
ence is made to the general purpose OS, and when the 
switch #3 is Input, since the switch is for common use, 
reference is made to the preferential interrupt table 156 
again to attain the intenupt objective operating system, 
such as the real time OS. 

[0042] Next, check is performed whether the inter- 
rupt objective operating system is equal to the operating 
system in execution (process 214). If the occurred Inter- 
rupt is not for the currently executed operating system, 
the operating system has to be once switched. This 
switching process is performed by requesting to the PS 
context switch module 127 (process 215), Next check Is 
performed whether the interrupt objective operating 
system is the general purpose OS 1 1 6 or the real time 
OS 117 (process 216). If the object is the general pur- 
pose OS 116, the inten-upt handler 122 of the general 
purpose OS is actuated with reference to the interrupt 
address table 155 (process 21 7). if interrupt for the real 



time OS Is caused, the inten^pt handler 123 of the rea) 
time OS Is actuated with reference to the interrupt 
^ address table 155, similarly [process 216). In general, 
when the task switching has to be perfonned by the 

5 interrupt process, the interrupt handlers 122 and 123 
call the re-schedulers 1 1 8 and 1 1 9 and do not return tiie 
control to the common Interrupt handler 128. However, 
if task switching is not caused, the process of the Inter- 
rupt handler Is terminated. At this time, the Interrupt 

TO handlers 122 and 123 return the control to the common 
intemjpt handier 128. The common interrupt handler 
128 resumes operation from the process 219. The proc- 
ess 21 9 Is the process for checking whether the operat- 
ing system is switched upon oocun^ence of inten-upt. 

IS When the operating system is switched by the process 
215, the operating system has to be switched again to 
return to the original execution environment Therefore, 
request is again made to the OS context switch module 
127 to execute the switching process (process 220). 

20 [0043] While discussion has been given herein- 
above for a method to make the input and output device 
in common in the system where a plurality of operating 
systems are operated on the single computer with refer- 
ence to the preferential intenrupt table stored in the 

25 Interrupt management table 1 29 from the common inter- 
rupt handler provided in the inter-OS control function 
124, the method set for above cannot handle all of the 
cases. For example, in input and output device, such as 
a graphic accelerator or a serial communication, oparat- 

30 Ing condition and various operation parameters are set 
from an input and output driver and holes the parame- 
tare and operating condition in the register within the 
hardware. For such input and output device, if the fore- 
going process is simply applied, the input and output 

35 drivers and interrupt handlers in respective operating 
systems cannot recognize switching of the operating 
systems to attempt to continue process from the condi> 
tion set by the input and output driver of the preceding 
operating system. However, the parameters to be set 

40 can be normal values only as continued from the value 
finally set by the input and output driver of own operat- 
ing system. It should be clear that the desired operation 
cannot be done if some parameter is written in the input 
and output device between switching of the operating 

45 system. 

[0044] In order to solve this problem, the present 
invention is characterized by application of a client- 
server model for the input and output process, such as 
the Input and output drivera 120 and 121 and the inter- 

50 rupt handler 122 and 123 provided in each operating 
system as shown in Fig. 14. Namely, with one of the 
input and output process of a plurality of operating sys- 
tems, an input and output process 222 on a server side 
is executed. The server side input and output process 

55 222 behaves to manage the input and output device 226 
common for a plurality of operating systems to execute 
data input and output 225 from tt^e input and output 
driver 121 to the input and output device 226 and to 
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operate for receiving the interrupt demand from the 
input and output device 226 by the interrupt handler 
123. Furthermore, receiving a notice of the request from 
the client side input and output process 221 to make 
judgment for the content to perform data input and out- 5 
put 225 with the input and output device 226, and 
returns the result to the client side input and output 
device 226 as a report of the result. On the other hand, 
the client side input and output device 221 transmits a 
notice 223 of request for data input and output to the jo 
input and output device 226. to the server side input and 
output device 222, for executing the input and output 
process using the retumed report of the result 224. 
Accordingly, the client side input and output process 
does not directly control the hardware of the Input and 75 
output device 226, and the server side input and output 
device constantly manages the input and output device. 
Therefore, no discrepancy will be caused in the operat- 
ing condition. 

[O045] It should be noted that the server side input 20 
and output process 222 is desirably set in the operating 
system having higher preferential order. In the shown 
embodimerit, since it Is assumed that the real time OS 
has higher preferential order than the general purpose 
OS, the server side input and output process 222 is pro- ss 
vided in the real time OS. By providing the server side 
input and output process, the operating system having 
higher preferential order can avoid occun-ence of mask- 
ing of the process, such as Interrupt demand. Accord- 
ingly, unduly delaying of response upon occurrence of 30 
the tntenupt demand can be avoided to attain a feature 
that missing of data can be avoided. 
100461 Hereinafter, among the modules shown in 
Rg. 14, process flow of the common Inten-upt handier 
126 and the interrupt handlers 122 and 123 will be dis- as 
cussed. 
[0045] 

{0047] Operational flow of the corrunon Interrupt 
handler 128 when the client-server model shown in Rg. 
14 is applied for input and output process, will be dis- 40 
cussed with reference to Rg. 1 5. It should be noted that 
the basic system construction is similar to Rgs. 1 and 5, 
and, in the preferential interrupt table 156. for the inter- 
rupt number of the input and output device to be com- 
mon for a plurality of operating systems, the common 45 
flag 1 is stored and for the interrupt number of the input 
and output device to be used in the particular operating 
system, the common flag 0 is stored. Furthennore, as 
shown in Rg. 14, the server side input and output proc- 
ess is provided in the real time OS 1 1 7 and the client so 
side input and output process is provided in the general 
purpose OS. 
(0046) 

[0048] The common interupt handler 128, at first, 
\3kes out the content of the executing OS storage 55 
parameter 154 after occun-ence of interrupt to check 
whether the cun-ently executed operating system Is the 
general purpose OS 1 16 or the real time OS 118 (proc- 



ess 230). Next, reference is made to the preferential 
interrupt table 156 (process 231). If the common flag is 
not set. the operating system, to which the occurred 
intemjpt corresponds, is attained with reference to the 
preferential Interrupt table 156 (process 232). If the 
common flag 1 is set, the interrupt objective operating 
system is determined by making Judgment of the con- 
tent of inten^jpt by accessing the input and output 
device (process 233). 

[0049] Next, check is performed whether the Inter- 
rupt objective operating system is equal to the operating 
system in execution (process 234). If the occurred Inter- 
rupt is not for the cumently executed operating system, 
the operating system has to be once switched. This 
switching process is performed by requesting to the PS 
context switch module 127 (process 235). Next, check is 
perfomied whether the interrupt objective operating 
system Is the general purpose OS 1 16 or the real time 
OS 1 17 (process 236). If the object is the general pur- 
pose OS 116, the Interrupt handler 122 of the general 
purpose OS is actuated with reference to the interrupt 
address table 155 (process 237). If intenijpt for the real 
time OS is caused, the interrupt handler 123 of the real 
time OS is actuated with reference to the interrupt 
address table 155. similarly (process 238). in general, 
when the task switching has to be performed by the 
interrupt process, the Inten-upt handlers 122 and 123 
call the re-schedulers 1 18 and 11 9 and do not return the 
control to the common interrupt handier 128. However, 
if task switching is not caused, the process of the Inter- 
rupt handler is terminated. At this time, the interrupt 
handlers 122 and 123 return the control to the common 
interrupt handler 128. The common interrupt handler 
1 28 resumes operation from the process 239. The proc- 
ess 239 is the process for checking whether the operat- 
ing system is switched upon oocun'ence of intenupt. 
When the operating system is switched by the process 
235, the operating system has to be switched again to 
return to the original execution environment Therefore, 
request Is again made to the OS context switch module 
127 to execute the switching process (process 240). 
[005O] Rg. 1 6 shows a process flow of the interrupt 
handier of the real time OS as a part of the server side 
input and output device 222 called from the common 
inten^upt handler 128, 

[0051] At first, the register in use is temponariiy 
stored in the Intenupt stack 153 (process 250), By mak- 
ing reference to the preferential intenoipt table 156, 
judgment is made whether the input and output device 
demanding interrupt Is common for a plurality of operat- 
ing systems (process 251 ). If not common. It is the inter- 
rupt demand for the real time OS to execute the 
corresponding interrupt process (process 253). if com- 
mon, reference is made to the preferential interrupt 
table 156 again to make judgment to which operating 
systems, the occuning interrupt demand corresponds 
(process 252). When the flag of the real time OS side is 
set or the common flag is not set, the Intenrupt process 
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for the real time OS interrupt is executed (process 253). 
When the flag of the general purpose OS side Is set, the 
interrupt process for the general purpose OS interrupt is 
executed (process 254). Here, the Interrupt process 254 
in the general purpose OS interrupt notifies occurrence 5 
of interrupt to the client side interrupt handler 122 to 
generate software interrupt to the general purpose OS 
116. Furthermore, If necessary, information obtained 
through the software interrupt process Is written In the 
common memory 125. It should be noted that the gen- w 
erated software inten^pt has to be provided lower pref- 
erential order than the interrupt process executed 
cun^ntly. In execution of the interrupt process for the 
general purpose OS intenrupt, since judgment for tasl< 
switching is not required for no influence to the real time 15 
OS at ail, the process of the interrupt handler123 Is ter- 
minated. Therefore, the register value temporarily 
stored in the inten'upt stack 153 is restored (process 
259), and the control is returned to the common inter- 
rupt handler (process 260). It should be noted that omit- 20 
ting of the process 255 is for speeding up of the 
process, and no problem will be arisen even in opera- 
tion to execute the process 255. 
[0052] On the other hand, after execution of the 
intenrupt process corresponding to the real time OS 2S 
imerrupt (process 253), Judgment is made whether task 
switching is necessary or not (process 255). If tasic 
switching Is necessary, process of the Interrupt handler 
123 is temninated. Therefore, the register value tempo- 
rarily stored on the interrupt stacic 1 51 is restored (proc- 30 
ess 259), and the control is returned to the common 
intenrupt handler (process 260). When Judgment is 
made that task switching is necessary, the register 
value temporarily stored on the interrupt stack 151 is 
copied in the task management table (process 256), 35 
and the temporarily stored register on the inten-upt stack 
is abandoned (process 257). Thereafter, the re-sched- 
uler 119 is actuated (process 258). It should be noted 
that if the processor 100 is provided with a function to 
increase and decrease the value of the Interrupt stack 40 
pointer 1 58 in conjunction with making reference to data 
on the memory, the processes 256 and 257 may be exe- 
cuted in a lump. 

[0053] On the other hand, the inten'upt handier 1 22 
of the general purpose OS actuated by the software 45 
imerrupt generated by the interrupt handler 123, exe- 
cutes the process of the same content as the operation 
flow with reference to Fig. 1 0 in most part. It should be 
noted that what is partially differentiated is execution of 
the interrupt process con-esponding to intenrupt shown so 
in the process 181. Information obtained therein is writ- 
ten in the common memory 125. Accordingly, the proc- 
ess 181 In the interrupt handler 122 read out the 
information stored in the common memory 125 to oper- 
ate to execution of the process corespondtng to the 55 
interrupt to realize the interrupt process without directly 
accessing the input and output devtee. 
[0054] On the other hand, even when the client- 



server model discussed In connection with Fig. 14 is 
applied and the input and output device Is in common 
for a plurality of operating systems, similariy to the dis- 
cussion given for Rgs. 11 to 13, It can occur a case 
where judgment cannot be made with which operating 
system the interrupt process is to be executed unless 
content of interrupt is checked. The process flow of the 
interrupt handler 1 23 provided in the real time OS 1 1 7 in 
this case will be discussed witt) reference to Fig, 17. It 
should be noted that the table for making judgment of 
the content of Interrupt is established under the premise 
where the switch table 200 is used In similar manner as 
that discussed above, the process discussed herein is 
applk:able not only for the switch but also for other Input 
and output device. 

[0055] At first, the register in use is temporarily 
stored In the interrupt stack 153 (process 270). By mak- 
ing reference to the preferential Inten-upt table 156, 
judgment is made whether the Input and output device 
demanding intemipt is common for a plurality of operat- 
ing systems (process 271 ). If not common, It is the inter- 
rupt demand for the real time OS to execute the 
corresponding interrupt process (process 274). If com- 
mon flag is set, the intenrupt objective operating system 
Is judged by making judgment of the content of interrupt 
(process 272), Comparing the content of interrupt and 
the switch table 200, when judgment is made that the 
dedicated switch for the real time OS is depressed, the 
real time OS 1 1 7 is stored as the interrupt objective OS, 
and when judgment is made that the dedicated switch 
for the general purpose OS is depressed, the general 
purpose OS 1 16 is stored as the inten-upt objective OS. 
On the other hand, when Judgment is made that the 
common switch is depressed, reference is made to the 
preferential Inten^jpt table 156, the operating system, 
for which the flag is set, is stored as the Intenrupt objec- 
tive OS. Here, considering the case where the stored 
values in the preferential interupt table 156 of Rg. 7 
and the switch table 200 of Fig. 12 are used, and IRQ#2 
is assigned to switch Intenrupt. when the switch #0 is 
input, reference is made to the real time OS, when the 
switch #2 is input, reference Is made to the general pur- 
pose OS, and when the switch #3 is input, since the 
switch is for common use, reference is made to the pref- 
erential Interrupt table 156 again to attain the interrupt 
objective operating system, such as the real time OS. 
[0056] Next, with reference to the inten-upt objective 
OS (process 273), if it is the real time OS 117, the inter- 
rupt process for the real time OS interrupt is executed 
(process 274). If it is the general purpose OS 1 16, the 
interrupt process 274 for the general purpose OS inter- 
rupt Is executed (process 275). Here, the Interrupt proc- 
ess 275 for the general purpose OS interrupt generates 
software interrupt for the general purpose OS 116 In 
order to notify the occurrence of interrupt to the client 
side inten-upt handler 122. Furthermore, if necessary, 
Infonnation obtained through the software inten-upt is 
written in the common memory 125. It should be appre- 
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dated that the generated software interrupt has to be 
provided lower preferential order than the Intenrupt proc- 
ess In execution. 

[0057] In interrupt process execution con-esponding 
to the general purpose OS intenupt, )udgment of tasic s 
switching is not necessary for not influencing to the real 
time OS at all. Accordingly, the process of the inten-upt 
handler Is terminated. Then, the register value tempo- 
rarily stored in on the interrupt stac)< 153 is restored 
(process 280), and the control Is returned to the com- w 
mon interrupt handler (process 281). It should be appre- 
ciated that omitting of the process 276 is for speeding 
up of the process, and no problem will be arisen even in 
operation to execute the process 276 > 
[0058] On the other hand, after execution of the is 
interrupt process corresponding to the real time OS 
interrupt, judgment is made whether tasic switching is 
necessary or not (process 276). If task switching is nec- 
essary, process of the inten-upt handler 123 is termi- 
nated. Therefore, the register value temporarily stored so 
on the interrupt stacic 1 53 is restored (process 280), and 
the control is returned to the common interrupt handler 
(process 281). When ludgment is made that tas)( 
switching Is necessary, the register value temporarily 
stored on the interrupt stacic 151 Is copied in the task ^ 
management table (process 277), and the temporarily 
stored register on the intenHjpt stack is abandoned 
(process 278). Thereafter, the re-scheduler 1 19 is actu- 
ated (process 279). 

[0059] As set forth above, the method to apply the so 
client-server model as the method for using the same 
Input and output devtee in common for a plurality of 
operating systems, has been discussed. Here, while 
discussion has been given for a method to notify the 
occurrence of interrupt from the server side operating as 
system to other operating system by software interrupt, 
If some communication means is provided, it becomes 
possible to notify oocun-ence of interrupt from the server 
side Input and output process 222 to the client side input 
and output process 221 . It can be replaced for the soft- 40 
ware interrupt set forth above. In the shown embodi- 
ment, In order to establish communication between two 
operating systems, the inter-OS communication func- 
tion 126 as shown in Fig. 1 is provided. Therefore, a 
method for making the Input and output device common 45 
for a plurality of operating systems will be discussed 
with reference to Rg. 18. 

[O060] Most of Components in Fig. 18 are the same 
as components discussed in connection with Figs. 1 
and 5, but are differentiated in a virtual input and output so 
driver 290 and a virtual inlen-upt handler 291 are pro- 
vided in place of the Input and output driver 1 20 and the 
Interrupt handler 122 provided in the general purpose 
OS 1 16. The virtual input and output driver 290 provides 
an Interface for accessing the input and output device ss 
from an appPication task but does not directly read and 
write the input and output devk;e and directly control the 
Input and output device. Here, using the message com- 



munication provided by the inter-OS communication 
function 126, reading and writing and control are 
requested to the input and output driver 121. Also, the 
result is also received from the Input and output driver 
121 using the message communication. The virtual 
interrupt handler 291 is actuated by the message trans- 
mitted from the intenrupt handler 123 to execute the 
interrupt process. 

[0061 ) Next, flow of the process upon occun^nce of 
the intemjpt demand for the input and output device 
common for both of the operating systems will be dis- 
cussed with reference to Fig. 18. For convenience of 
illustration, in the preferential interrupt table of the inter- 
rupt number generated by the input and output device 
handled herein, the common flag 1 is set, and also, the 
flag is set on the side of the general purpose OS. 
[0062] The interupt demand generated by the input 
and output device is once trapped in the common inter- 
rupt handler 128. The process is executed according to 
the flow of Rg. 15. Here, since it is assumed that it Is 
Interrupt from the Input and output device In common for 
both of the operating systems, the inten-upt handler 123 
provided in the real time OS Is actuated. The interrupt 
handier 123 executes the process according to the flow 
discussed in connection with Rg. 16. Here, since it is 
assumed that common flag is set In the preferential 
interrupt table 156 and flag is set in the general purpose 
OS, the interrupt process 254 conrespondlng to the gen- 
eral purpose OS inten-upt is executed. Here, the inter- 
rupt process 254 for the general purpose OS intenvpt 
transmit the message to the virtual intenrupt handler 291 
on the client side using the inter-OS communication 
function in order to notify occun-ence of intenrupt to the 
virtual interrupt handler 281 on the client side. It should 
be noted that infonnation obtained through the interrupt 
process may be transmitted with attaching to the mes- 
sage, and may transmit information by writing In the 
common memory 1 25 and making reference to from the 
virtual intemrpt handler 291. Furthermore, when a mes- 
sage queue for receiving the message is not provided in 
the virtual interrupt handler 291, the message is trans- 
mitted once to the server task 1 12 provided as the appli- 
cation task and the virtual intemjpt handler 291 is called 
from the server task 1 12 for actuating the virtual inter- 
rupt handler 291 . The virtual Inten-upt handler 291 exe- 
cutes the intenrupt process by making reference to the 
resutt of process of the inten-upt process attached to the 
message or the common memory 1 25 . 
[0063] Furthermore, the flow of process for execut- 
ing the input and output process requested from the 
task provided In the general purpose OS will be dis- 
cussed with reference to Rg. 19. The virtual input and 
output driver 290 in the general purpose OS is only 
interface for accessing the input and output device from 
the office work IS, and requested input and output proc- 
ess is transferred to the input and output driver 121 
using the inter-OS communication function 126. It 
should be noted that the infomiation obtained by the vir- 



12 



23 EP 1 054 

tual input and output driver 290 may be transmitted with 
attaching to the message, and also may be written in 
the common memory 1 25 and made reference to from 
the input and output driver 121 for transferring informa- 
tion. Furthermore, when the message queue for receiv- 5 
ing the message is not provided in the input and output 
driver 121, the message is transmitted once to the 
sen/er task 1 13 provided in the application task to actu- 
ate the input and output driver 121 by calling the input 
and output driver 121 from the server task 113. The jq 
input and output driver 121 executed the input and out- 
put process by making reference to the content of 
request attached to the message or the common mem- 
ory 125, 

[0064] Next, flow of re-writing of the preferential is 
Intemjpt table provided In the inter-OS control function 
124 will be discussed with reference to Fig. 20, The 
preferential interrupt table 156 Is re-written by the man- 
agement task 115 managing the user demand or so 
forth. However, It Is possible to cause mismatching 20 
when the Inten-upt process makes reference to the pref- 
erential interrupt table during re-writing of the preferen- 
tial intemjpt table 156. Therefore, Initially, all inten-upt 
demand is masked so as not to cause any interrupt 
(process 301). It should be appreciated that it is also 2S 
possible to mask only interrupt demand for the Inten^pt 
number for which re-writing is to be effected. After set- 
ting the Interrupt mask, the content of the preferential 
intemjpt table 156 is updated (process 302) and then 
the set intenupt mask is released (process 303) to per- 30 
mlt re-writing of the preferential interrupt table 1 56. 
[0085] As set forth above, the method to make the 
input and output device common for a plurality operating 
systems has been discussed, an example of application 
of the present Invention for a graphic display of a built-in 35 
equipment having a user tntertace, such as a vehicle 
mounted navigation system, as practical application, 
will be discussed with reference to Rg. 21. It should be 
noted that the operating system operated on the graphic 
display systems are the general purpose OS 1 16 and 40 
the real time OS 117 similarly to Rg. 1, and a 
task/thread operating on the real time OS is assumed to 
have higher preferential order than a task/thread operat- 
ing on the general purpose OS. 

[0086] The graphic display device has graphic driv- 45 
ers 310 and 312 parsing command for drawing and dis- 
playing and controlling a graphic hardware 314, graphic 
interrupt handlers 311 and 313 to be actuated by the 
intemjpt demand generated by the graphics hardware, 
and the graphic hardware 314 displaying an image data so 
developed to the pixels. The graphic hardware 314 has 
a frame memory 316 storing luminance value of each 
pixel and display control 315 taking out the luminance 
value of each pixel from the frame memory 31 6 per ver- 
tical synchronization frequency to output to the display ss 
104. Here, in the frame memory, conflict of resource Is 
avoided by making the a drawing region 31 7 for general 
purpose OS storing Image generated by the graphk; 
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driver 310 of the general purpose OS and a drawing 
region 318 for the real time OS storing Image generated 
by a graphic f¥driver 312 of the real time OS independ* 
ent or separated. By this, upon switching of the operat- 
ing system, respective drawn image are stored. Even 
when the operating system Is switched again, the proc- 
ess can be continued from the condition before switch- 
ing. On the other hand, rt Is assumed that the graphic 
drwer 312 and the graphic interrupt handler 313 pro- 
vided In the mat time OS operate as server, and the 
graphic driver 31 0 and the graphic Interrupt handler 31 1 
provided in the general purpose OS operate as client 
[0067] Operational flow In drawing and dlqDiay 
demand from the applteation task Incorporated in the 
real time OS will be discussed at first. The application 
task calls the drawing command provided In the graphic 
driver 312 to execute the drawing process. The drawing 
command Is consisted of command for drawing line or 
polygon and commands designating attribute, such as 
line width, blotting pattern. The graphk; driver 312 
parses the drawing command to develop the pixels in 
the drawing region 318 for the real time OS. If the 
graphic hardware 314 includes an acceleration function 
executing developing the pixels by hardware, such func- 
tion may be used. When drawing Is completed, then, the 
display command provided In the graphic driver 312 is 
executed. The display command Is consisted of a dis- 
play start address in the frame memory 31 6 and a com- 
mand designating a display size to display the image 
designated by controlling the register in the display con- 
trol 315. When the displaying of the designated Image is 
started, the display control generates an interrupt 
demand. The interrupt demand Is once trapped in the 
common interrupt handler 128, and instantly judged as 
the intenrupt demand from the common device to call 
the graphic interrupt handler 313. By this, tlie graphic 
interrupt handler 313 detects that the image is dis- 
played. 

[0068] Next, operational flow in the drawing and dis- 
playing demand from the application task Incorporated 
In the general purpose OS 116 will be discussed. The 
application task calls drawing command provided In the 
graphic driver 310 to develop the pixels In the drawing 
region 317 fbr the general purpose OS. When drawing 
is completed, then, the display command provided In 
the graphic driver 310 Is executed. The display com- 
mand transfers message designating the display start 
address and the display size in the frame memory 316 
to the graphic driver 312 using the inter-OS communica- 
tion function 126. The graphic driver 312 receiving the 
demand displays the designated image by controlling 
the register in the display control 315. It should be noted 
that the graphic driver 312 makes judgment display 
demand from which operating systems has higher pref- 
erence, to constantly display the frame memory to be 
preferentially displayed. When displaying of the desig- 
nated Image is started, the display control 315 gener- 
ates the Interrupt demand. The interrupt demand is 
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once trapped by the common interrupt handler 128, and 
instantly judged as Interrupt demand from the common 
device to actuate the graphic interrupt handler 313. The 
graphic inten-upt handler 313 transfers the received 
interrupt demand to the graphic interrupt handler 31 1 5 
using the inter-OS communication function 126. By this, 
the graphic interrupt handler 31 1 detects that the image 
is displayed. 

[0069] The particular embodiment of the graphic 
display system, to which the present Invention has been w 
discussed hereinabove, various peripheral devices, 
such as serial/network communication, CD-ROM/DVO- 
ROM storage device, can be made common for a plural- 
ity of operating systenris by application of the present 
invention. 75 
[0070] According to the present invention, in the 
computer system operating a plurality of operating sys- 
tems with the single processor, the same input and out- 
put device can be used in common from the application 
tasks executed by respective operating systems to per- zo 
mit reduction of total number of the input and output 
devices. Furthemiore, according to the present Inven- 
tion, the input and output device common for a plurality 
of operating systems and the input and output driver for 
data Input and output, and the inten'upt handler are 2s 
loaded in one operating system, and by requesting input 
and output process to the input and output driver and 
the Inten-upt handler from the other operating system, 
the input and output process can be continued without 
resetting the input and output device to Improve opera- 30 
bility. 

[0071] Although the present invention has been 
illustrated and described with respect to exemplary 
embodiment thereof, it should be understood by those 
skilled In the art that the foregoing and various other 35 
changes, omission and additions may be made therein 
and thereto, without departing from the spirit and scope 
of the present invention. Therefore, the present inven- 
tion should not be understood as limited to the specific 
embodiment set out above but to include all possible 4o 
embodiments which can be embodied within a scope 
encompassed and equivalent thereof with respect to the 
feature set out In the appended claims. 

Claims 45 

1 . A computer system comprising: 

a plurality of operating systems; and 
OS switching means for switching a plurality of so 
operating systems, said OS switching means 
making reference to a preferential inten-upt 
table on the basis of an interrupt factor for 
switching to corresponding operating system 
and calls Inten'upt processing means incorpo- 55 
rated in said operating system. 

2. A computer system as set forth in claim 1 , 



wherein said preferential interrupt table 
stores whether the inten^pt is from a peripheral 
device common In a plurality of operating systems 
or not in addition to the operating systems to be 
actuated per intemipt factor. 

3. A computer system as set forth in claim 2, 

the OS switching means makes reference to 
the preferential intemjpt table on the basts of 
Interrupt factor, makes Judgment whether the 
Interrupt demand is for inten-upt common for a 
plurality of operating systems, detemrilnes 
operating system to be objective for interrupt by 
parsing the content of the peripheral device 
generating interupt as judged to be common 
Inlen^pt, for switching the operating system, 
and In conjunction therewith for calling interrupt 
processing means provided in said operating 
system. 

4. A computer system comprising: 

a plurality of operating systems; 

OS switching means for switching a plurality of 

operating systems; 

peripheral device to be common for a plurality 
of operating systems; 

data inputting and outputting server for input- 
ting and outputting data with the peripheral 
device to be used in common, providing in one 
of the operating systems; and 
data Inputting and outputting client for inputting 
and outputting data with the operating system 
other than said one operating system, request- 
ing inputting and outputting data to said data 
inputting and outputting server and executing 
inputting and outputting of data by receiving a 
result of data Inputting and outputting with the 
peripheral server in the data inputting and out- 
putting server. 

5. A computer system as set forth in claim 4, 

which further comprises a preferential interrupt 
table storing operating system to be actuated 
per Interrupt factor and preferential interrupt 
table re-writing means for re-writing the prefer- 
ential inten^pt table. 

said OS switching means makes reference to 
the preferential interrupt table per intenupt fac- 
tor, makes judgment whether the interrupt 
demand is for interrupt to be common for a plu- 
rality of operating systems, and calls interrupt 
processing means included in said data input- 
ting and outputting server if Judged as common 
intenupt. 
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6. A computer system as set forth in daim 4. wherein 

said data inputting and outputting server is pro- 
vided in a region managed by the operating 
system having the highest preferential order. s 

7. A computer system as set forth in claim 4. 

which comprises inter-OS communication 
means for mutual communication between a io 
plurality of operating systems, 
said data inputting and outputting server and 
said data Inputting client means are communi- 
cated. 

IS 

8. A computer system as set forth in daim 5, wherein 

said data Inputting and outputting server ts pro- 
vided in a region managed by the operating 
system having the highest preferential order. zo 

9. A computer system as set forth in claim 5, 

which comprises inter-OS communication 
means for mutual communication between a 25 
plurality of operating systems, 
said data inputting and outputting server and 
said data inputting client means are communi- 
cated. 
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